做了 9 年產品經理，B2B、B2C 都做過。

如果要我現在回想，一個產品專案通常是怎麼開始的，我大概可以很快列出一條流程：

理解使用者問題 → 競品研究 → 跟 UX 討論 → 定義流程 → 寫 PRD → 跟工程師評估 → 開發 → 上線 → 看數據 →再迭代。

這套流程我做了很多年。

我一直覺得 PM 很重要的一件事情，就是把複雜的東西變簡單，讓使用者比較容易理解。

但最近一年，我開始有一個很強烈的感覺：

這件事情好像不用再這樣做了。

不是說 UX 不重要了，也不是說產品不需要設計了。

而是我開始覺得，我們過去產品設計裡一個很理所當然的前提，可能正在改變。

以前是：

讓使用者理解系統。

現在 AI 開始讓我們有機會做到：

讓系統理解使用者。

而這兩件事情，其實差非常多。

先從一個我最近真的遇到的案子開始

最近接手了一個新的專案。

這個專案原本是別人負責，交接的時候，前一個 PM 特別提醒我一件事情：

「這個 User 很不懂技術。」

而且不只是「不懂技術」而已。

他跟我說，這個 User 很容易講著講著就離題，而且每次開會都會花非常久的時間。

聽到這裡，我第一個想法其實很簡單：

完了:) 。

因為我最怕的就是開一個一小時的需求會議，最後大家花了很多時間，但其實沒有真的確認到需求。

所以這次我決定不要按照以前的方式做。

以前可能會是：

需求訪談 → 整理需求 → 寫 PRD → 畫 Wireframe → 開會確認。

但這次我想：

如果文字很容易讓彼此理解不同，那乾脆不要先講那麼多文字。

直接做一個看得到的東西。

於是我拿了前面留下來的一份簡單需求訪談紀錄，先自己整理出我理解的需求，再用 AI 幫我快速產生一個可以互動的 Mockup。

它不是最後要上線的 UI。

甚至不是完整的 Prototype。

它比較像是：

「這是我目前理解的你的需求，你看看是不是這個樣子？」

結果比我預期的好很多

第一次開會，我們花了一個小時。

前台的主要規格，幾乎全部確認完。

第二次開會，再把後台、也就是內部人員使用的流程確認掉。

最後我再把完整的畫面和 PRD 文字整理好，讓 User 最後再體驗一次並 Sign-off。

這次經驗讓我印象很深。

因為以前如果遇到一個「不懂技術、又容易離題」的 User，我可能會想：

我要怎麼把需求問得更清楚？

我要怎麼把產品講得更簡單？

我要怎麼讓他理解我在說什麼？

但這一次，我換了一個方法：

我不要求他先理解我的產品語言。

我直接做出一個東西，讓他看著畫面告訴我：

「不是，我想要的是這個。」

反而更快。

這是我第一次很明確感受到：

**AI 不只是幫 PM 做 Prototype 快一點。

它開始改變 PM 跟使用者溝通的方法。

但真正讓我開始思考這件事情的，其實是另外一個案子

前一個專案，我們曾經花不少時間設計一個分類表單。

當時我們很認真討論：

這些分類怎麼拆？

名稱要怎麼取？

哪些東西應該放在一起？

使用者進來之後，要怎麼找到自己要申請的東西？

這其實就是非常典型的 PM 工作。

我們一直在想：

怎麼讓 User 更容易找到他要的功能？

最後做出來之後，老闆卻不是很滿意。

他的問題很直接：

「為什麼一定要讓 User 自己分類？」

我一開始其實有點愣住。

因為我們不是已經把分類做得很清楚了嗎？

但他接著講了一個我覺得很有意思的例子。

假設今天是一個企業內部系統。

員工可能需要申請「轉職派任」。

但問題是：

員工真的知道這件事情叫「轉職派任」嗎？

這個詞可能是 HR 的專有名詞。

對 HR 來說很自然。

但對一般員工來說，他可能根本不知道這個流程在系統裡被叫什麼。

他真正知道的可能只是：

「我好像要被外派到另一個地方。」

「那我是不是要申請什麼東西？」

這時候，如果我們要求他：

先理解公司的分類 → 找到正確名詞 → 選擇正確表單 → 開始申請

其實我們是在把系統的理解成本丟回給 User。

那為什麼不能反過來？

如果今天 User 只需要說：

「我接下來要被外派到上海，我需要辦哪些事情？」

系統自己去理解：

- 這個人想做什麼
- 他現在的情境是什麼
- 可能涉及哪些申請
- 哪個流程才是正確的
- 背後應該由哪個承辦人員處理

那 User 根本不需要知道：

「這件事情在公司的系統裡叫什麼。」

這個差異看起來很小。

但其實它代表的是完全不同的產品設計思維。

我們可以開始讓系統理解 User

這也是我最近一年做 AI 產品時，最大的體悟。

以前的產品邏輯比較像：

> User
>  ↓
> 理解系統
>  ↓
> 找到分類
>  ↓
> 選擇功能
>  ↓
> 填寫表單
>  ↓
> 完成任務

但 AI Native Product 開始可以變成：

> User
>  ↓
> 描述自己的情境
>  ↓
> AI 理解 Intent + Context
>  ↓
> AI 找到適合的流程
>  ↓
> AI 執行 / 協助完成
>  ↓
> User 確認

這個改變的重點，其實不是「聊天介面很酷」。

也不是「以後大家都用 Chatbot」。

而是：

誰負責理解，開始改變了。

這也是我想開始這 30 天的原因

所以接下來這 30 天，我不想單純介紹：

哪個 AI 工具很好用。

哪個 Agent 很厲害。

哪個模型又更新了。

我反而想從產品經理的角度，重新看一次我們每天都在做的事情。

如果今天重新設計：

• Search
• Form
• Menu
• Workflow
• Dashboard
• Customer Service
• Agent
• Prototype
• PRD

它們還需要長得跟以前一樣嗎？

我也想把這些觀察整理成一個比較具體的東西：

AI Native Product Design Patterns。

不是 30 個 AI 案例而已。

而是 30 個我認為值得重新思考的產品設計模式。

也許做了九年 PM，我真正需要重新學習的，不是怎麼用 AI。

而是：

當系統開始懂人之後，我們到底還要怎麼設計產品？

明天開始，就從最熟悉的東西開始——介面。